fix: Allow POST requests without Content-Type header when body is empty#759
fix: Allow POST requests without Content-Type header when body is empty#759kabir merged 2 commits intoa2aproject:mainfrom
Conversation
Per RFC 9110 §8.3, Content-Type header is only meaningful when a message
body is present. The HTTP+JSON transport was incorrectly returning 415
(ContentTypeNotSupportedError) for POST requests with no body and no
Content-Type header.
This fix adds validateContentTypeForOptionalBody() method to handle
endpoints like POST /tasks/{id}:cancel where the body is optional. When
the body is null or empty, Content-Type validation is skipped. When body
content is present, Content-Type must still be application/json.
This allows bodyless POST requests to be processed correctly and return
appropriate errors (404 TaskNotFoundError, 409 TaskNotCancelableError)
instead of 415.
Fixes a2aproject#747
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves an issue where HTTP POST requests lacking a body but also a Content-Type header were incorrectly rejected with a 415 'ContentTypeNotSupportedError'. By implementing a new validation logic that respects RFC 9110's guidance on Content-Type header applicability, the system now correctly processes bodyless POST requests, allowing for appropriate business logic errors (like 404 or 409) to be returned instead of a generic content type error. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request correctly addresses an issue where POST requests with an empty body were incorrectly rejected due to a missing Content-Type header. The introduction of validateContentTypeForOptionalBody is a clean solution that correctly handles endpoints with optional bodies, like cancelTask. The implementation is sound and follows the logic described in the RFC. I have one minor suggestion to further improve the code.
reference/rest/src/main/java/io/a2a/server/rest/quarkus/A2AServerRoutes.java
Outdated
Show resolved
Hide resolved
…verRoutes.java Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
Per RFC 9110 §8.3, Content-Type header is only meaningful when a message body is present. The HTTP+JSON transport was incorrectly returning 415 (ContentTypeNotSupportedError) for POST requests with no body and no Content-Type header.
This fix adds validateContentTypeForOptionalBody() method to handle endpoints like POST /tasks/{id}:cancel where the body is optional. When the body is null or empty, Content-Type validation is skipped. When body content is present, Content-Type must still be application/json.
This allows bodyless POST requests to be processed correctly and return appropriate errors (404 TaskNotFoundError, 409 TaskNotCancelableError) instead of 415.
Fixes #747 🦕